Communication mechanism and method for easily transferring information between processes

ABSTRACT

A communication mechanism and method for assisting in the transfer of information between at least two processes through a data storage system is provided. The communication mechanism is provided between a protocol family and the process, and is capable of communicating with both. Both the processes and the protocols may differ depending on the functions desired. In the preferred embodiment of the invention, the communication mechanism is a socket interface which it utilized through the use of a series of calls contained in a socket library. The calls contained in the socket library are used to create a socket, and such socket is then used to effectuate a transfer between at least two processes through a data storage system to another process.

BACKGROUND OF THE INVENTION

The invention relates generally to a communications mechanism forassisting in the easy transfer of information between processestypically running on different host processors. Particularly, theinvention relates to a communication endpoint structure which allowsdifferent application processes, or simply processes to be utilized intransferring information between processes via a data storage system.

For example, file transfers between different computers are usually doneusing a communication protocol over a network. Examples of well knowncommunication protocols include the System Network Architecture Protocol(SNA) and Transmission Control Protocol/Internet Protocol (TCP/IP). Inaddition to the communications protocol an application program orprocess, such as FTP (File Transfer Protocol) is layered on top of aprotocol to effectuate a file transfer over a communication protocolsuch as TCP/IP.

Most application processes are written to use an application programminginterface (API) for effectuating transport services. The API serves asmeans for allowing two processes to communicate with one another, andhide the implementation of transport details to the processes. A socketis an communication endpoint or a transportation structure most commonlyused with a UNIX® operating system, although it is not limited to a UNIXoperating system. The socket is an object which identifies thecommunication endpoints between the two processes. The socket APItypically hides the protocol of the network architecture or the computersoftware architecture present in the host processors that theapplication processes are placed on. Thus, a socket allows the easyassociation of an endpoint such as an application process, any protocol,or protocol implementation.

As stated, file transfers between different computers are often doneover a network. A file transfer is an example of a process that uses thenetwork to moves files between different processes. The processes mayreside on different host processes or even on the same host processor.These files may be moved through a network. File transfers may also bedone without the presence of a network. EMC Corporation, assignee of thepresent application and pending application Ser. No. 08/723,137 which isincorporated herein by reference, discloses a file transfer processeswhich is used by processes on two different computers to communicate,not through a network, but through a data storage system. However, theuse of such a file transfer process does not currently provide an easymeans of enabling communication between the file transfer processes, orany other process such as one typically used by a user.

It is therefore desired to provide a communication mechanism capable ofeasily communicating between different processes through a data storagesystem. It is also desired to have a communication mechanism which canbe used by processes which offer different services or functions. Thepresent invention through the use of the communications mechanism andmethod described hereafter allows for a data storage system to be usedas a median for the transfer of data, while allowing for differentprocesses to be used with a single communications mechanism.

SUMMARY OF THE INVENTION

A communication mechanism for at least first and second processescontained on a plurality of host processors connected by a data storagesystem is provided. The communication mechanism includes at least oneinterface which is capable of enabling communication via the datastorage system, where the interface is contained on each of theplurality of host processes, and in the preferred embodiment of theinvention the communication mechanism is resident in each of theprocesses to facilitate the communications between the processes.

Also included in the invention is a plurality of computer system calls.The computer system calls are available to the user of one process tocommunicate with another processes, where the processes are connectedthrough a data storage system. The calls are used to first, obtain acommunications mechanism which effectuates the communications betweenthe different processes. Once the communications mechanism is obtained,a local address is created for the communications mechanism.Subsequently, a connection is established between the differentprocesses which, upon the occurrence of some additional steps allows forthe transfer of data and messages between the different processes.

The invention also includes a method for using a communication mechanismto transfer information between at least first and second processesthrough a data storage system. The method includes the steps of creatinga communication mechanism, and then using the created communicationmechanism to create a connection between the first and second processes.Once the communication is established, information can be transferredbetween the first and second processes through the data storage system.

In accordance with another aspect of the invention a system includes aplurality of host processors, on which a plurality of processes reside.The host processors include local storage, and the host processes areconnected to a data storage system. Also resident on each of theplurality of host processors is a communication mechanism which permitsinformation stored in the local storage area to be transferred throughthe communication mechanism, to the data storage system using thecommunication mechanism and then to a processes on another one of theplurality of host processors.

The invention also includes a data storage system for transferringinformation from a first process to a second process. Each one of theprocesses is running on a different host processor. Each host processoris connected to the data storage system. The data storage systemcomprises a plurality of storage devices and also has a shared storageregion into which both the first process and the second process shareaccess. Implemented on at least one of the plurality of storage devicesis a control block table which serves to allocate a communicationmechanism for a first process when the first process wishes to establisha connection to the second process so that information can betransferred from one process to another via the data storage system.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and further advantages of the present invention may be betterunderstood by referring to the following description taken inconjunction with the accompanying drawings in which:

FIG. 1 is schematic block diagram of a prior art mechanism to transferinformation without the communication mechanism of the presentinvention;

FIG. 2 is a schematic block diagram of a system including thecommunication mechanism of the present invention; and

FIG. 3 is a block diagram showing the logical placement of thecommunication mechanism of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

As is known, a traditional socket is similar to a UNIX file mechanism inthat it provides an endpoint for communication. The need for socketsarose partially because those processes needed to be able to initiateand facilitate communications to different destination points or endpoints. Such end points would typically be another process.

Because such processes usually need to utilize different protocols, theprocess must be capable of explicitly specifying that an address is anIP address. Traditional processes request the operating system (UNIX,for example) to create or allocate a socket as needed. Once a socket iscreated the operating system returns an integer that the process thenuses to reference the just created socket. It should be noted that whena socket is created it is not bound to a destination address, as it isnot even bound to a local address. A socket must be bound to a localaddress prior to being able to connect, much less communicate with aprocess at a different destination address. However, it is up to theprocess whether to supply an address when the socket is used or as incommon in with a TCP/IP connection, the process can bind the destinationaddress to the socket, and thus is not required to keep having tospecify the destination address.

As noted earlier, the process in pending patent application Ser. No.08/723,137 does not contain the communications mechanism of the presentinvention. The earlier process does, of course, contain a communicationmechanism in order to transfer the files, it does not do so an easy orefficient manner as will be explained in conjunction with FIG. 1.

Referring to FIG. 1, a block diagram which shows a file transferprocess, without use of the present invention, is shown as 19 and 19′.The overall system which embodies the prior art includes a plurality ofhost processors 12 and 12′ that are connected to a central data storagesystem 14. Host processors 12 and 12′ are typically digital processingunits which include one or more CPUs and main memory. They might be, forexample PCs, workstations, symmetric multiprocessors, or a massivelyparallel processor which contains many CPUs.

In general, data storage system 14 contains a shared memory (not shown)that is accessible to all of the host processors that are connected tothe data storage system 14. The control structures and transfer buffersthat are stored in the shared memory provide a mechanism by which onehost processor can transfer files to and receive files from another hostprocessor that is connected to the data storage system 14.

Still referring to FIG. 1, host processors 12 and 12′ are connected todata storage system 14 through respective host connections 16 and 16′.Data storage system 14 contains the physical memory in which data isstored. The particular manner in which the physical memory within thedata storage system 14 is implemented and how it is partitioned is notof central importance. Examples of commercially available products thatcan be used to implement data storage system 14 are the Symmetrix 3XXXand 5XXX series family of Integrated Cached Disk Array® products fromEMC Corporation of Hopkinton, Mass., assignee of the present invention.The ICDA devices are high-performance integrated cache disk arraysdesigned for on-line data storage. It should be understood that otherdesigns known to persons skilled in the art may also be used toimplement data storage system 14.

The system of FIG. 1 also includes local storage 24 attached to the hostprocessor 12. Local storage 24 may be included with the host processor12 or may be part of a separate data storage system.

If host processor 12 has a UNIX operating system, local database 26contained in local storage 24 could be any one of numerous databaseswhich work with the UNIX operating system. An example of such a databasewould be those produced by Oracle Corporation. When using a proprietarydatabase such as. Oracle, any files extracted by the host computer 12through an process 20, such as an extractor, would have to be placed ina sequential file format prior to transfer to the second host processor12. Typically, proprietary databases provide a process in which thedatabases are capable of creating sequential files through the extractprocess. This translation into a sequential file must occur prior to thetransfer of any files to the second host processor 12. This, as is wellknown in the art, must occur because the format used by an Oracledatabase to store any files is unique to the Oracle database whichoriginally created the file.

It should be noted that communication mechanism 18, which is built intothe process 19, is not truly capable of directly interfacing with theprocess 19 shown in FIG. 1. In order for the communication mechanism 18to receive or obtain the desired file information from the process 19,the file transfer process 19 must generate a separate file which canthen be accessed by the communication mechanism 18. Thus, there is notany actual interaction between the file transfer process 19 and thecommunication mechanism 18, and additional steps are required, withinthe process 19 to effectuate getting the file to the communicationmechanism 18.

The communication mechanism 18 for the process 19 has to be built intothe process 19, as the process 19 is designed. Therefore, if it isdesired to use another or different process, communication mechanism 18is not of any use. Any other process will have to include its own uniquecommunication mechanism 18 in order to communicate with any otherprocess. This means that all processes require additional functions inorder to accomplish a similar function.

Second host processor 12′, also has its own communications mechanism 18′within file transfer process 19′. Another process is shown as a loader22. When communications mechanism 18′ receives the sequential file fromthe host processor 12, the communications mechanism 18′ writes thesequential file into a file when can then be accessed by the filetransfer process 19′. The file transfer process 19′ can then write thereceived file into the local storage 30. Local storage 30 also containssequential file storage 32 and storage for a proprietary database whichis running on the host processor 12′. If, for example, host processor12′ is a mainframe computer that has an MVS operating system such asthose manufactured by IBM Corporation, an example of a proprietarydatabase which runs on an MVS operating system is DB2. DB2 is alsoproduced by IBM.

After the sequential file is written into the sequential file storage 32the loader 22 reads the sequential file from the sequential file storage22 and loads it into the storage for it's proprietary database 34. Itshould be understood by those skilled in the art, that a conversionprogram (not shown) needs to be present in both host processors toconvert a received sequential file into the format of the databaserunning on the host processor. In this example, host processor 12 needsto convert the sequential file received from host processor 12 into aformat suitable for a DB2 database.

Referring to FIG. 2, a system 50 which includes the present invention isshown. The system 50 includes a plurality of host processors 12 and 12′that are connected to a data storage system 14. As in the prior art,host processors 12 and 12′ are digital processing units which includeone or more CPUs in main memory.

Data storage system 14 also contains a shared memory, such as a cachememory, that is accessible to all of the host processors that areconnected to the data storage system 14. The control structures andtransfer buffers that are stored in the shared memory provide amechanism by which one host processor can transfer files to and receivefiles from another host processor that is connected to the data storagesystem. The host processors 12 and 12′ are each connected to the datastorage system 14 through respective host connections 16. To simplifythe discussion, only a single host connection is shown for eachprocessor. It should be understood, however, that there could in fact bemultiple communications between the data storage system and a processor.

Data storage system 14 contains a physical memory, such as disk drives,in which data is stored. The manner in which the memory within thestorage system is implemented and how stored data is partitioned is notof importance to the present invention. Examples of commerciallyavailable products that can be used to implement data storage system 14are the Symmetrix 3XXX and Symmetrix 5XXX series of data storageproducts from EMC Corporation.

Each of the host processors 12 and 12′ is connected via host connections44 to local storage 46 and local storage 48 respectively. It should beunderstood local storage 46 and local storage 48 may be part of therespective host processors 12 and 12′, or separate data storage units.Other processes such as an extractor and a loader are shown as 42 and 47respectively. Local storage 46 and local storage 48, in the inventionrepresent proprietary storage, such as that which would be provided byproprietary databases such as DB2 by IBM for host processors having anMVS operating system, and an Oracle database which is provided forprocessors having a UNIX operating system. Prior to and after thetransfer of information between processes 19 and 19′, the use of theprocesses 42 and 47 is similar to that explained earlier.

Each of the host processors 12 and 12′ also includes a communicationmechanism 52, within the processes 19 and 19′ which will be described ingreater detail. In the preferred embodiment of the invention,communications mechanism 52 comprises a socket applications programminginterface, which is responsive to a set of procedures whereby varyingprocesses, such as those shown at 19 and 19′, on the different hostprocessors 12 and 12′ can use to communicate with one another throughthe data storage system 14. The use of the communication mechanism 52allows processes 19 and 19′ to directly interface with the communicationmechanism 52 without having to generate a file to be separately accessedby the communications mechanism 52. Therefore, the communicationmechanism 52 acts as a transparent means to allow processes 19 and 19′to communicate with one another, and also allows for processes withdifferent functions to be used with the same communication mechanism 52.

In the prior art as demonstrated in FIG. 1, communication mechanism 52did not include the socket applications programming interface, butinstead was a communication vehicle individually placed into eachprocesses Therefore, any process, such as the earlier file transferprocess was not capable of easily communicating with another process.

FIG. 3 is a logical block diagram showing how the communicationmechanism 52 interacts with both processes and a particular protocol.Communication mechanism 52 is capable at of interacting with any one ofa number of processes shown as 64. For example, process 64 could includethe aforementioned FTP, PTP (Process to Process) and Telnet, as thecommunication mechanism 52 allows the transport vehicle, the protocol62, to be transparent to the process, regardless of the type or functionof the processes 64. Beneath the communication mechanism 52 is theprotocol 62. In the preferred embodiment of the invention the protocol62 is a protocol used to pass messages or files between at least twohost processors through a data storage system. The protocol representsthe actual rules used to pass messages through the data storage system.It should be understood that the protocol allows the transfer ofmessages or files between a host processor that has a UNIX operatingsystem (or another operating system such as NT) and a second hostprocessor using a MVS or mainframe operating system, or any combinationthereof. The details of the protocol are not particularly relevant here,as it is merely the transport vehicle. The important fact is that thecommunication mechanism 52 is interposed between the processes 64 and aprotocol 62, and is capable of effectuating communications between twohost processors through a data storage system.

In the preferred embodiment of the invention, communication mechanism 52is a socket interface that enables the processes 19 and 19′, againreferring to FIG. 2, to communicate in a transparent manner with theprotocol being used to transport information to and from the datastorage system 14.

A library is provided to the user of the processes to provide a set ofprocedures that the processes running on each of the host processorswill use to establish communications with each other. As willsubsequently be explained, the library includes a plurality of differentcalls which are used to effectuate different functions required for thecommunication to occur with the data storage system 14. In the preferredembodiment of the invention the library is a set of function or socketcalls.

Generally, a socket is allocated or created with a socket call to asocket interface, residing within the processes 19 and 19′ of FIG. 2. Tocreate a socket, a socket call is used. The following is the structureof the socket call:Socket (domain, type, protocol)

The socket call is used to create or allocate the socket from the datastorage system. The newly created socket will then be able to begin anduse the connection and communication process between two processes, suchas those shown in 19 and 19′ in FIG. 2. In the preferred embodiment ofthe invention the call is:STPsocket(PF_STP, SOCK_STREAM,PF_STP)

PF_STP represents the protocol family. AF_STP may also be used in placeof AF_STP if it is desired to use an address family instead of aprotocol family. In this case the Symmetrix Transport Protocol (STP) isused by the socket to facilitate communication over the data storagedevice. SOCK_STREAM represents the type of communication used, which isa reliable stream delivery service, and PF_STP is the identification ofthe specific protocol family, STP, used by the socket.

The use of the above socket call actually has the process resident onthe host processor obtaining a free socket control block from thecontrol block called STP socket table (not shown) resident on the datastorage system. Thus, the STP socket table allocates a free socket whenthe user of the process wishes to create a socket. In the preferredembodiment of the invention the STP socket table resides on disk driveson the data storage system 14. It should be understood the STP sockettable could reside elsewhere, such as in a shared memory. Placing theSTP socket table on the disk drives allows for the STP socket table tobe recoverable, as is well known in the art, with a RAID (redundantarrays of intelligent disks) storage system, case of problems with thedata storage system.

When the socket has been allocated by the STP socket table, the STPsocket call returns a non-negative integer to the user of the process toidentify the allocated socket. A copy of the allocation is then madeinto the process memory. A newly created socket, however, does not haveany connection or association to a local or destination address. A localaddress usually needs to be established for the for the process usingthe socket so the process can specify to the host processor a port foritself to effectuate communications. In order to establish a localaddress for itself the bind call is used:STPbind(socket, localaddr, addrlen)

Socket, within the STPbind call, is the integer descriptor of the socketto be bound, and is available to the user of the process once the socketis created. Localaddr is the structure that specifies the local addressto which the socket will be bound, and addrlen represents the length ofthe address. In the preferred embodiment of the invention, the userwould insert the integer descriptor of the socket, a local address whichincludes the system name, the Symmetrix Transport Group (STG) name (i.e.STG), a port number, and the length of the local address. If a portnumber is not supplied, as would be the case when the process is aclient versus a server, a free port from the specific STP port file willautomatically be assigned to the socket. If the STPbind call issuccessful, the system returns a zero value to the process.

Until now all that has been described is how to create a socket, and howto bind a local address to the created socket. In order to accomplishthe desired goals of the process, there are additional functions whichhave to be utilized before actually transferring any data or sending anymessages to another process through the data storage system.

Typically the process that initiates the connection is termed a clientprocess, while the process which accepts or listens to the clientprocess is termed the server process. These terms are usually only usedprior to the connection being established, as is subsequently described.

It is desired that the process use a connect call to establish aconnection with another process. In this invention the other process istypically a remote connection partner resident on another hostprocessor. See FIG. 2. A socket connect call is used to establish aconnection between two processes. The connect system call is as follows:STPconnect(socket, name, addrlen)

Socket is the integer descriptor of the socket to be connected to theprocess. Name is the socket address structure that specifies the nameand destination address of the other process (i.e. server remoteconnection partner). Addrlen specifies the length of the destinationaddress, and is usually measured in bytes. It should be understood thatwhen establishing a connection, the process attempting to establish theconnection must wait until the other server or remote process “accepts”the request. The server process being connected may include a queue ifit is not ready to accept a request.

Once the connection is established throughout the use of socket betweentwo processes, both processes can send and receive data. The next set ofcalls are used for the message exchange between the processes to sendand receive data through the sockets. In order to send data from oneprocess through the data storage system to another process the followingcall is used:STPsend(socket, message, length, flags)

The STPsend call is used to send data, as the sockets within eachprocess have been connected. For the STPsend call, socket identifies thealready called socket to be used to send the data. Message is used togive the address/buffer location of the data to be sent. Lengthindicates the number of bytes of data to be sent, and flags, if used,can indicate a variety of different items. For example, one value forflags can allow the process to request the message be sent with routingtables local to the process. Flags are typically used to permit theinitiating process to have some control of the routing of the messagebeing sent. However, for a message or data to be sent through the datastorage system, flags need not necessarily be used.

Obviously, once the initiating process sends the data it must bereceived by the other or remote process. Referring again to FIG. 2, datais sent, for example, from process 19 containing a communicationmechanism 52 over connection 16, through data storage system 14, overconnection 16′ to be received by process 19′, which containscommunication mechanism 52. Data storage system 14 uses a shared memoryregion, such as a cache memory (not shown) shared by both processes 19and 19′ to both establish the connection and to send and receiveinformation or data. An example of how a shared memory region is used inthis manner is shown in Applicant's prior pending patent applicationSer. No. 08/723,137. Process 19′ needs to be capable of receiving datasent by the process 19 through the communication mechanism 52. Process19′ will receive the data through the communication mechanism 52, whichas already indicated, as been connected to process 19. The STPrecv callis used by the process 19′ to receive messages or data from the process19. The STPrecv call is used as follows:STPrecv(socket, message, length, flags)Socket specifies the socket from where the data is being received.Message is used to specify the address or buffer location into which thereceived data will be placed upon receipt. Length specifies the lengthof the buffer location, and flags, in this call, are used to permit theprocess that initiated the receive request to control the reception ofthe sent data by the sending process. If a MSG_PEEK argument is used forflags, the data will be returned to the initiating process, but notdeleted from storage. Therefore, if a subsequent STPrecv call is used,the same data will be returned again. Remember, once the connection isestablished files, data or messages may be sent in either direction notjust from 19 to 19′.

After the desired data is sent through one socket and received by theother process, the connection established must be terminated. TheSTPclose call is used to terminate a connection. The initiating processwaits for the communication to be completed, and then releases the allof the resources used for the communication. The STPclose call is asfollows:STPclose(socket)

The user simply has to identify the socket to be closed. A connectionmay also be terminated while a communication is still ongoing. TheSTPshutdown call is capable of stopping the transfer of data in one ormore directions. The STP shutdown call is as follows:STPshutdown(socket, how)

The socket to be shutdown needs to be identified. How can have a valueof zero (0), one (1), or two (2). If the value of how is zero, incomingdata to the socket will be stopped. If the value of how is one, dataoutgoing from the socket will be stopped. If the value of how is two,all communication will cease. If the value of how is two, the call worksthe same way as does the STPclose call.

The above described calls demonstrate how to use processes to create asocket, establish a connection with another process, through a datastorage system, send/receive data between two processes through the datastorage system and terminate the connection and/or communication withthe use of the shared memory region on the data storage system.

Other calls are available to the user in order to permit the user toexercise additional control over the sockets. A list of the callsavailable to the user to control the sockets within processes residingon host computers connected with a data storage system is providedbelow.

It is understood that there are processes that are capable of using onlyone type of socket. It is contemplated by the present invention that atranslating header program, which is another process, such as thoseshown at 42 and 47 in FIG. 2, is made available to the processes so ifthe process is capable of only using a different type of socket (i.e.TCP/IP), the process can use the translating header program to translatethe socket calls the process has into the desired format. In this casethe desired format is the use of STP sockets and STP socket calls. Thenthe process has the communication mechanism necessary to communicatewith a protocol capable of communicating with a data storage systemwithout having to change the processes.

A summary of the typical library calls, as indicated above, along withtheir functions, are listed below. STPaccept Used by the server partnerto complete a connection request initiated by the client. The serverchooses the client which is on top of the queue of connection requests.STPbind Used to insert the local address into the Socket Control Block.This information will be used by the STPlisten call to inform clientsthat a server is ready for communication. STPclose Used to close aconnection. STPconnect Used by the client partner to request aconnection with a server. STPgethostbyname Used to return to the callerthe STP address using a host name. STPgethostname Used to return to thecaller the STP address of the current socket. Used if the caller doesnot call STPbind but expects to have a default address assigned to it.STPgetpeername Used to return to the caller the name of the connectionpartner. STPgetsockopt Used to obtain information about socket optionsconfiguration. STPlisten Used to configure the maximum queue of pendingconnection requests. STPrecv Used to read data by the connectionpartner. STPsend Used by a communicating partner to send data to itspeer. STPsetsockopt Used to modify (set) socket optional configuration.STPsocket Each communicating partner must first call STPsocket to obtaina Socket Control Block where control information of the connection isstored.

The following are also library calls available to the user of process.The only difference from the calls above, is that these calls cannot beused with those of a different type of socket library (i.e. TCP/IP).These calls are useful in certain operating environments, particularlyan MVS one. STP error Reports to the caller additional error informationwhich is specific to the socket over STP implementation STPgetoptReturns the current value of an STP specific parameters. STPsetopt SetsSTP parameters. STPstrerror Returns to the user a pointer to a stringwhich provides text associated with the last STP specific error.STPgivesocket Used by one process to make a specific socket available toa STPtakesocket call issued by another process. STPtakesocket Used by aprocess to acquire a socket from another process.

The principles of the underlying communication mechanism can be used forany kind of transfer, not just the transfers as described herein.Although the communication mechanism of the present invention has beendescribed for use with a Symmetrix data storage system, it iscontemplated that the communications mechanism of the present inventionis capable of being used whenever processes wish to communicate witheach other through a data storage system.

Having described the preferred embodiment of the present invention, itwill now become apparent to those who are skilled in the art that otherembodiments incorporating it's concepts may be provided. It is felt,therefore, that this invention should not be limited to disclosedembodiment, but rather should be limited only by the spirit and scope ofappended claims.

1. (canceled)
 2. A communication mechanism for transferring informationbetween different processes, said communication mechanism comprising: atleast one interface for enabling the transfer of information via a datastorage system, a plurality of computer system calls available to a userof said processes to establish a connection between said processes, andbegin said transfer of information.
 3. (canceled)
 4. The communicationmechanism of claim 2, wherein said processes run on different hostprocessors and each processor is connected to said data storage system,and in which said interface runs within each of said plurality ofprocesses.
 5. (canceled)
 6. The communication mechanism of claim 2,wherein said interface is socket interface.
 7. The communicationmechanism of claim 6, wherein said socket interface is allocated fromsaid data storage system. 8-15. (canceled)
 16. A method for transferringinformation between at least first and second processes residing onprocessors separately connected to a data storage system via the datastorage system, the method comprising the steps of: creating acommunication mechanism; using said communication mechanism to create aconnection between said first process and said second process; andtransferring information from said first process via said data storagesystem to said second process.
 17. The method of claim 16, wherein saidfirst and said second processes reside on different host processors, andsaid host processors are connected to said data storage system.
 18. Themethod of claim 17 including a termination step for enabling one processto terminate said connection to said second process.
 19. The method ofclaim 18 further comprising the step of: allocating, from said datastorage system, said communication mechanism.
 20. (canceled)
 21. Asystem comprising: a plurality of host processors, wherein each hostprocessor includes a plurality of processes resident on of each of saidhost processors; a local storage area connected to each of saidplurality of host processors; a data storage system separate from saidplurality of host processors and connected to each of said plurality ofhost processors; and a communication mechanism resident within each oneof said plurality of processes, in which information stored in saidlocal storage area is transferred by one of said communicationmechanisms via said data storage system to said communication mechanismresident within another one of said plurality of processes; saidcommunication mechanism including an interface that communicates withsaid plurality of processes, wherein said plurality of processes havedifferent functions. 22-26. (canceled)